我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。

我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。

前兩篇整理 ERP 導入過程時，我嘗試把 FDE 的工作分成兩個階段。第一個階段是先理解現場實際怎麼運作，確認使用者口中的規則有哪些適用範圍與例外；第二個階段則是當公司對未來流程還沒有答案時，把懸而未決的問題記錄下來，整理選項與影響，再交給真正有權限的人做 Decision。

到了生產與備料流程，還會遇到另一類問題。公司的流程可能已經決定好了，負責的人也很清楚，但實際執行到某一個節點時，最後仍然會回到「由人判斷」。這種人工判斷有些可以再往下拆成明確規則，有些則會刻意保留彈性，另外還有一些資訊最後會被寫進 ERP 的備註欄位，讓下一個部門看到之後再決定怎麼處理。

這算是流程還沒有被標準化嗎？

流程已經走得很清楚，到了「怎麼選」還是回到人

ERP 顧問在介紹工單與備料流程時，系統本身有替代料的機制。替代料可以先維護在系統裡，也可以設定自然替代，讓系統在備料時按照庫存與設定，自動帶出可以使用的替代料。

但這家公司前面已經討論過，生產領料不會混料，因此不打算使用自然替代。即使系統知道某個料號有哪些替代料，這一次到底要不要改用替代料，仍然由生管或物控人員判斷，再直接到工單上調整實際使用的料件。

這時候從流程圖來看，其實已經相當完整。訂單成立之後開工單，工單展開 BOM，再進入備料、領料與生產。系統知道標準 BOM，也知道替代料關係，真正沒有交給系統決定的，是「這一次要不要用替代料」。

類似的人工判斷也出現在預計完工時間。顧問在討論工單日期時，提到某些壓克力類產品可能抓十五到二十天的生產與出貨時間，工單則可能再往前兩三天完成，預留後面的入庫與出貨作業。 逐字稿可以看到這些經驗值存在，但沒有看到十五天、十八天或二十天分別對應哪些規格、數量、加工方式或產能條件。這表示企業可能已經有足以支撐日常排程的經驗，經驗背後的判斷條件仍然有一部分留在人的工作知識裡。

從這兩個案例來看，既然還有人工判斷，表示規則還不夠清楚，所以應該繼續把規則問出來，盡可能放入數位系統。但實際參與營運流程時，我認為還需要考慮另外一種情況。

一個被大量使用的備註欄位，可能正在承接系統沒有結構化的資訊

在一些 ERP 流程裡，可以看到營運人員很依賴備註欄位，而且這些備註不是留給自己看的，而是會跟著訂單、工單或料件一路傳到下一個部門。當重要資訊必須透過自由文本跨部門傳遞時，至少代表這些資訊目前沒有被完整結構化。

原因可能來自系統。ERP 沒有適合的欄位可以描述這個條件，使用者只好把資訊寫在備註裡；也可能來自流程本身，大家知道某些情況需要特殊處理，但還沒有整理出足夠明確的分類與判斷方式。

還有一些情況，保留備註其實是公司刻意做出的妥協。

例如某些原物料在細節規格上可能存在差異，但成本相差不大，實際用途也很接近。如果為每一個細微差異都建立不同料號，Master Data 很快就會增加大量相似項目，採購、生管與現場人員反而更難判斷自己應該選哪一個。公司最後可能選擇讓這些材料共用同一個料號，真正有特殊要求時，再把細節寫進備註，由後面的批備料人員依照當時訂單與現場情況判斷。

這種作法犧牲了一部分資料結構化程度，換來比較簡單的料號管理與使用方式。對系統設計來說，它看起來不夠乾淨；對每天需要找料、採購與備料的人來說，建立十幾個非常接近的料號也未必比較好。

因此，備註欄位裡存在重要資訊，確實是一個值得注意的訊號，但它不一定直接代表系統設計有問題，也不一定代表企業流程不成熟。需要繼續理解的，是這些資訊為什麼沒有被結構化，以及把它結構化之後，實際可以換到多少價值。

「人工判斷」的下一個問題，是這個模糊度為什麼存在

從 FDE 的角度來看，如果流程裡出現「到時候人工判斷」、「生管決定」、「現場看狀況」這類描述，這裡必須先確認，這個人實際上拿什麼資訊做判斷。

以替代料為例，可以進一步訪談：什麼情況會考慮替代料、有哪些替代料可以選、不同產品或客戶是否有不同限制，以及兩個替代料都可以使用時，現場如何決定。這些問題目前在逐字稿裡沒有完整答案，因此不能直接替這家公司寫出一套規則，但它們會是下一輪需求探索需要確認的內容。

如果幾位有經驗的人面對相同條件，通常都會做出相同決定，那麼這個人工判斷很可能只是還沒有被外顯的規則。如果每次都需要大量考慮客戶要求、當天庫存、品質狀況、現場設備與其他訂單，而且不同情境很難事先窮舉，那麼保留人工判斷本身也可能是合理的流程設計。

料號與備註的例子更能看出這個差異。如果拆成不同料號之後，可以明顯降低拿錯料的風險、改善成本分析或提升採購品質，那麼增加 Master Data 複雜度可能值得；如果規格差異很小、發生頻率很低，而且現場本來就很容易透過備註辨識，再新增大量料號可能只是把一個簡單的人工作業換成更高的系統維護成本。

因此，人工判斷背後真正需要分析的，是 決策的結構化價值與結構化成本。

Decision Table 可以幫助判斷，這個判斷規則到底清楚到什麼程度

遇到人工判斷時，一個我認為適合使用的工具是 Decision Table。它和前一篇提到的決策紀錄處理的是不同問題。

不同於「公司還有哪些事情沒有決定、誰應該負責決定」；Decision Table 則是在公司已經知道某個營運角色需要做判斷之後，繼續整理「什麼條件會得到什麼結果」。

假設我們想釐清替代料，可以先用下面這種形式開始訪談：

真正使用時，需要和生管、物控及流程 Owner 一起確認條件是否完整，以及不同的人是否真的會按照相同方式判斷。

Decision Table 的價值也不只是為了下一步寫程式。當一件事情從「這個就看情況」慢慢整理成幾個可以討論的條件，FDE 才有辦法判斷這個判斷規則已經成熟到什麼程度。

有些判斷規則最後可能非常穩定，適合交給系統自動處理；有些只能整理出大部分規則，少數例外仍然需要人確認；也有一些在整理之後會發現，判斷高度依賴當下 Context，繼續把規則拆細只會產生大量難以維護的例外。

這時候 Decision Table 的功能就不是強迫所有判斷變成規則，而是幫助團隊知道規則的邊界在哪裡。

FDE 要決定的，還包括「這件事值得被結構化到什麼程度」

如果把替代料、交期經驗值與備註欄位放在一起，我認為 FDE 在這個階段需要避免一個很容易出現的方向：看到人工判斷，就把目標設定成消除人工判斷；看到自由文字，就想辦法全部改成下拉選單與結構化欄位。

企業系統需要標準化，但標準化本身也有成本。

多一個欄位，就需要有人維護；多一種料號，就需要有人辨識與管理；多一條規則，就需要處理規則變更與例外；如果再進一步自動化，還要確保系統取得的資料足以支撐判斷規則。

因此，我目前會把這類問題分成幾個層次來看。

如果判斷條件非常清楚，而且不同人面對相同條件會得到相同答案，可以考慮把規則結構化，甚至讓系統自動執行。如果大部分條件明確，但仍有少數例外，可以讓系統先縮小選擇範圍或提供建議，再由人做最後確認。如果判斷規則需要大量現場 Context，但這些資訊可以被系統整理，也可以讓系統負責準備資料，把判斷留給人。

還有一些情況，保留備註與人工判斷可能就是合理答案。前提是團隊知道這是刻意留下的彈性，也知道最後由誰負責判斷，而不是因為沒有人有時間釐清，所以所有事情都往備註欄位裡面放。

對 FDE 來說，這個差異很重要。需要被解決的是沒有被看見的模糊度；已經被理解，而且經過取捨後刻意留下的模糊度，可以是系統與人之間的一種分工。

Decide 到 Encode：先理解人怎麼決定，再決定系統要承接多少

用我之前整理的五層 FDE 工作框架來看，這一篇案例主要落在 Decide 到 Encode 之間。

上一篇的 Decide，處理的是公司到底選哪條流程、誰有權限決定，以及尚未完成的議題決策如何被記錄與往上推進。到了這一篇，流程可能已經決定由生管、物控或其他角色負責，但還需要往下理解這個角色實際上怎麼做營運流程判斷。理解完成之後，就會進入 Encode。

Encode 也不只有「寫成自動化規則」一種結果。系統可以直接做自動化判斷，也可以限制可以選擇的範圍；可以提供建議，也可以只把庫存、訂單、歷史備註與其他 Context 整理好，最後仍然由人判斷。有些少數且低價值的例外，甚至可以繼續保留自由文字。

因此，「人工判斷」和「備註」其實透露很重要的訊號。它們可能代表系統功能的缺口，也可能代表 Decision Rule 還沒有被整理完成，但有時候，也可能是企業在資料結構化、Master Data 複雜度與現場彈性之間做出的妥協。FDE 需要把這些情況分辨清楚，再決定哪一部分值得讓系統承接，以及哪一部分留給人，反而能讓整個流程維持比較合理的平衡。

有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！